Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-044.txt

Text File | 1992-11-18 | 50.8 KB | 1,428 lines | [TEXT/MPS ]

C.S.M.P. Digest             Tue, 07 Apr 92       Volume 1 : Issue 44

Today's Topics:

    Speech synthesis toolkit
    Using Think C with the new Apple #includes
    Tail Patches
    Using Think C with new #includes, part II
     MacApp3 & C++
    Question about SWIM programming
    char to keycodes
    New Programmer Needs Help!!
    Speaker-independent continuous-speech recogni
    How do I pass a string to an object in THINK C?
    FixMul tip
    Very Simple Questions
    "Please insert disk ^0" Help
    Error recovery in THINK C (was Re: Suggestion to the Developers of Think C)


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Brendan T. McNichols)
Subject: Speech synthesis toolkit
Date: 2 Mar 92 18:37:49 GMT


Hi all,

I was wondering if anyone out there knows of any speech synthesis
toolkits for the Mac.  That is, something which will take a file of text
and turn into speech with appropriate pauses and voice inflections.  I
know there is a group working on this on NeXT workstations, but haven't
heard anything from the mac world.

Thanks,
Brendan

--
Brendan T. McNichols, Computer Engineer               [phone]
Psyracuse U. Sychology Dept.             [e-mail] (NeXT)
430 Huntington Hall               [e-mail] (ASCII)
Syracuse, NY 13244                              [e-mail]



- -------------------------

From: [e-mail] (Rick Pavek)
Date: 3 Mar 92 22:51:10 GMT
Organization: Boeing

In article <[e-mail]> [e-mail] writes:
>
>Hi all,
>
>I was wondering if anyone out there knows of any speech synthesis
>toolkits for the Mac.  That is, something which will take a file of text

Yesterday, on Good Morning America, John Scully and one of the Apple
Engineers (the inventor) displayed Casper, the talking computer.

The computer spoke with near human quality speech, understood spoken commands from Joan London, John and the Employee, and showed how Apple Computer intends
to develop it's product.

Looked neat as stuff.  They selected text, pasted into MacWrite, changed
the font, size and style of text, and did all kinds of things.

They indicated it was still a prototype.  Why they announced it, I don't know.
Perhaps they had it developed far enough along that they could display it
to the public and beat someone else (TI?) to it.

All I know is...  I want it.

Cheers

- --
Rick Pavek                          v-------------------------------v
[e-mail]          v IBM     UBM     We all BM     v
AppleLink:  kuryakin                v              4IBM             v
GEnie:      r.pavek1                v-------------------------------v

- -------------------------

From: [e-mail] (Brendan T. McNichols)
Date: Wed, 4 Mar 92 13:00:19 EST

>In article <[e-mail]> [e-mail] (Rick
>Pavek) writes:
>In article <[e-mail]>
>[e-mail] writes:
>>
>>Hi all,
>>
>>I was wondering if anyone out there knows of any speech synthesis
>>toolkits for the Mac.  That is, something which will take a file of
>>text
>
>Yesterday, on Good Morning America, John Scully and one of the Apple
>Engineers (the inventor) displayed Casper, the talking computer.
>
>The computer spoke with near human quality speech, understood spoken
>commands from Joan London, John and the Employee, and showed how Apple
>Computer intends to develop it's product.
>
>Looked neat as stuff.  They selected text, pasted into MacWrite, changed
>the font, size and style of text, and did all kinds of things.
>
>They indicated it was still a prototype.  Why they announced it, I don't
>know.  Perhaps they had it developed far enough along that they could
>display it to the public and beat someone else (TI?) to it.

Actually, they didn't beat anyone.  The technology that Caspar is based
upon was developed fully on NeXT workstations at Carnegie-Mellon and is
available as a commercial product as we speak from the commercial arm of
CMU, called Visus.  This is not actually what my original post was about,
though, what I need is text-to-speech software, not speech recognition
software.  Anyway, I need SOFTWARE, not VAPORWARE!  :)  :)  :)

>
>All I know is...  I want it.
>

Then buy a NeXT!  :)

>Cheers
>

Cheers to you too!
Brendan

>--
>Rick Pavek                          v-------------------------------v
>[e-mail]          v IBM     UBM     We all BM     v
>AppleLink:  kuryakin                v              4IBM             v
>GEnie:      r.pavek1                v-------------------------------v
>
- --
Brendan T. McNichols, Computer Engineer               [phone]
Psyracuse U. Sychology Dept.             [e-mail] (NeXT)
430 Huntington Hall               [e-mail] (ASCII)
Syracuse, NY 13244                              [e-mail]

---------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject: Using Think C with the new Apple #includes
Date: 2 Mar 92 22:05:03 GMT
Organization: Kalamazoo College

On the February 1992 CD ("20000 Leagues under the CD"), Apple provided
the new MPW includes:  version 3.2.1.  If you want to use those headers,
there are a few small changes to make.  I found a few of them on my own.
Symantec will probably come out with the official new headers soon, but
these work for me.

The following changes are necessary to get my own large TCL project to
work.  Your mileage may vary:

In Sound.h
- --------

replace:
typedef long Time;

with:
#if !THINK_C
typedef long Time;
#endif

replace:
    Time wait;

with:
#if THINK_C
    long wait;
#else
    Time wait;
#endif


In Types.h
- --------

Cut the #if THINK_C...#endif group (15 lines or so) from the old
Types.h, and paste it just after the line "#define __TYPES__".

replace:
#define nil 0

with:
#ifndef nil
#define nil 0
#endif

Around the "#ifdef mc68881...#else...#endif" group (10 lines or so), put
"#if !THINK_C" and "#endif".

replace:
typedef long (*ProcPtr)();

with:
#if !THINK_C
typedef long (*ProcPtr)();
#endif


In QuickDraw.h
- ------------

Search for the text "danger", and read the note about the new definition
of "Pattern".  Note that at least one TCL class, CPaneBorder, wants the
old definition.

To be compatible, insert directly before the first enum in the file:
#define dangerousPattern


In Traps.h
- --------

Insert, somewhere, the line:
#define _GestaltDispatch 0xA0AD

[Note:  I think this trap was only accessed from CApplication.c;  if
you're not using the TCL, you probably won't need to change this.]


Remember to re-compile precompiled headers after making any changes, and
you may want to "Use Disk" to force THINK C to recognize that the
headers have changed.
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



- -------------------------

From: [e-mail] (Phil Shapiro)
Date: 3 Mar 92 22:38:51 GMT
Organization: Symantec Corp.

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:

   On the February 1992 CD ("20000 Leagues under the CD"), Apple
   provided the new MPW includes: version 3.2.1.  If you want to use
   those headers, there are a few small changes to make.  I found a
   few of them on my own.  Symantec will probably come out with the
   official new headers soon, but these work for me.

It's unclear if this will happen or not. We did a diff on all of the
header files, and (as far as I know) didn't find anything that much
different. They mostly changed the spacing for a bunch of prototypes
and changed a ton of #defines to enums (or vice versa, I forget).

   Search for the text "danger", and read the note about the new
   definition of "Pattern".  Note that at least one TCL class,
   CPaneBorder, wants the old definition.

   To be compatible, insert directly before the first enum in the
   file: #define dangerousPattern

Remember all of that flak about THINK C 5.0 aligning even-sized
character arrays in structures? Well, this was part of what that
feature was intended to fix. If you don't turn off the array alignment
in C 5.0, then the old, "dangerous" Pattern type will work fine on
68000 machines. See Appendix J in the MPW 3.2 Release Notes on ETO #6
for more info about this problem.

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

---------------------------

From: [e-mail] (Scott Bronson)
Subject: Tail Patches
Date: 2 Mar 92 22:07:45 GMT

This seems like it would be a fairly common question, but I have not
been able to find any FAQ adressing it.

How does one intercept keyboard and mouse events without writing a tail
patch?  I understand tail patching is a bad thing because it may break
any bug fixes Apple releases that relies on the address of the trap.
I've lived under that rule (happily) so far, because with a bit of artful
coding, one can usually get around that restriction (for instance, rather
than patching CopyBits, patching GetResource is a much better idea.  I was
rather proud of that one).

However, I can see no way to intercept and dispose of keyboard events
without tail patching GNE or WNE.  Mouse events are taken care of quite
nicely by a patch to FindWindow, but I was surprised at how few
applications actually call MenuKey after recieving a keydown event with
the command key held down.

I also can't figure out how to intercept the user selecting a menu item
without tail patching MenuSelect or MenuKey.  The user gets to choose
which items he or she wants to intercept, so I don't think I can take
care of the event before the Menu Manager gets ahold of it.  Then Apple
says I can't take care of it immediately afterwards.

How do macro programs do it?  Is patching the keyboard driver or the
ADB manager viable?  I sure hope not--that sounds like an inherently
unstable idea.

Do any of you have any ideas of where to look for docs describing this,
or what traps to patch to intercept these events?  Would there happen to
be any sample code out?  Thanks very much for *any* help at all you might
be able to offer!


   - Scott            +----------------: SCOTT BRONSON :-----------------+
+---------------------|  [e-mail]    [e-mail] |
|       /_  /)        | 6850 El Colegio Road #234; Goleta, CA 93117-4300 |
|        / /_)        +==================================================+
+=========================+



- -------------------------

From: [e-mail] (Ari Halberstadt)
Organization: Eclectic Associates, Inc.
Date: Tue, 3 Mar 1992 05:06:00 GMT

In article <scott.699574065@mcl> [e-mail] (Scott Bronson) writes:
>How does one intercept keyboard and mouse events without writing a tail
>patch?  I understand tail patching is a bad thing because it may break
>any bug fixes Apple releases that relies on the address of the trap.

For GNE, you can write a filter whose address is stored in the GNEFilter
low memory global. WNE calls GNE, so this will work. You can also head
patch GNE, then use OSEventAvail (don't use EventAvail) to see if
the event of interest is in the queue. To change the event using this
method you'd probably have to walk the event queue, which is not a good
idea (despite poor DTS sample code supposedly showing how to check
for command-period while processing an Apple Event). Another, probably
safer method to change events is to patch PostEvent. Then you can change the
event before it ever gets into the queue! Of course, update and activate
events are never placed in the regular queue, but from your post it
sounds like you're only interested in mouse and keyboard events.

>I also can't figure out how to intercept the user selecting a menu item
>without tail patching MenuSelect or MenuKey.  The user gets to choose
>which items he or she wants to intercept, so I don't think I can take
>care of the event before the Menu Manager gets a hold of it.  Then Apple
>says I can't take care of it immediately afterwards.

The patches and GNE filter described above should be able to modify
events which MenuKey would see. I don't know how to get around the
MenuSelect problem; I'm actually quite curious about MenuSelect,
since there are so many menu enhancing utilities which must modify
its behavior.

>How do macro programs do it?

One way macro programs can work is by using the Event Manager's journaling
mechanism, but I'm not sure if that method is still fully supported.
Another way is to post events into the queue (using PostEvent). The most
modern approach is to use a scripting language and Apple Events, though
your market may be a little limited since not many programs fully implement
Apple Events.
- --
Ari Halberstadt       [e-mail]             #include <std/disclaimer.h>
Ramsgate (n.) All institutional buildings must, by law, contain at least twenty
ramsgates. These are doors that open the opposite way to the one you expect.
    -- D. Adams & J. Lloyd "The Meaning of Liff", p75.

- -------------------------

Organization: Penn State University
Date: Tuesday, 3 Mar 1992 03:40:40 EST
From: Christopher Tate <[e-mail]>

In article <[e-mail]>, [e-mail] (Ari
Halberstadt) says:
>
>For GNE, you can write a filter whose address is stored in the GNEFilter
>low memory global. WNE calls GNE, so this will work.

I'm starting to discover that the jGNEFilter hook isn't entirely
reliable.  There are times when my filter routine seems not to get
called at all, for various amounts of time (more than a minute, in
some cases).

This is all under System 7 on a IIsi.

Has anyone else observed this behavior?  I don't recall running into
any such problems with System 6; did System 7 change the way the
jGNEFilter was handled?

- -------
Christopher Tate     | Cryptogram #25:
[e-mail] |
[e-mail]  | "AUBE IBPB CQHA JPGYZMPE NJHAXBZ, SJZG JS
- ---------------------|  IMWFYZK MZG GJKH MZG *VUPYHAXMH MZG AUB HZJI."
"*" == proper nouns  |             -- "M VUYWG'H *VUPYHAXMH YZ *IMWBH"

---------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject: Using Think C with new #includes, part II
Organization: Kalamazoo College
Date: Mon, 2 Mar 1992 22:34:17 GMT

In QDOffscreen.h
- --------------

Open the old QDOffscreen.h and cut the lines that begin..
#if THINK_C
    mapPix = 1L << mapPixBit,
    newDepth = 1L << newDepthBit,

...and end...
    gwFlagErr = 1 << gwFlagErrBit
#endif

Open the new QDOffscreen.h.  Replace the lines defining mapPix through
gwFlagErr with the lines from the old QDOffscreen.h.


In PrintTraps.h
- -------------

Apple has removed the inline code from all the old print traps'
definitions.  There doesn't seem to be an appropriate library to
include, either.  My fix was to replace the 25 definitions in the new
Printing.h, from PrPurge() to PrDrvrVers(), with the 25 declarations
from the old PrintTraps.h, from PrPurge() to PrStlInit().  I'd think
there'd be a better way to do this, though...
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



- -------------------------

From: [e-mail] (Pete Gontier)
Date: Tue, 03 Mar 1992 01:42:02 -0500

 JR> From: [e-mail] (Jamie R. McCarthy)

 JR> Apple has removed the inline code from all the old print traps'
 JR> definitions.

Yowza! I noticed this one earlier today. WHY on earth would they do such
a thing? I can only imagine the new glue checks for the existence of the
trap, then runs the glue if it's not there, but how many people develop
for systems which require that nowadays? Can't those people just be stuck
with using "Printing.h" instead of "PrintTraps.h"? Is DTS really spending
so much time answering dumb questions about the difference between the
two files? Why not just document the differences *inside the two files*?

Sorry to rave, but I'm the kind of guy who defines SystemSevenOrLater
because the Gestalt glue calls GetTrapAddress twice before _GestaltDispatch,
which I already did, dammit, and I don't want anybody using anything
scary like System 6.0.3 in 1992 anyway.

---------------------------

From: [e-mail] (Ameet Zaveri)
Subject:  MacApp3 & C++
Date: 3 Mar 92 00:21:14 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <u_banzai.699236134@mcl> [e-mail] (Buckaroo Banzai) writes:
>So, when IS MacApp 3.0 coming out??????

MacApp 3.0 will be available on ETO #7 which should reach developers in
mid-March. It is in production and shipping right now.

- - ameet zaveri



- -------------------------

From: [e-mail] (Kent Sandvik)
Date: 5 Mar 92 20:30:56 GMT
Organization: MacDTS Mongols

In article <u_banzai.699236134@mcl>, [e-mail] (Buckaroo Banzai) writes:
>
> So, when IS MacApp 3.0 coming out??????
>
> Anyone know?

Golden Master is ready, and is shipping with the ETO#7 out next week or so. The
final APDA product will be ready later when documentation if final.

Kent Sandvik/DLE*)

*) DLE - Dynamic Language Evangelist

---------------------------

From: [e-mail] (Lawrence Kelly)
Subject: Question about SWIM programming
Date: 3 Mar 92 01:07:11 GMT
Organization: Carderock Division, NSWC, Bethesda, MD

Just wondering if anyone has done any type of direct programming of
the SWIM chip in systems so equipped.  Is there a standard Mac system
call to use SWIM commands, or would you have to do direct SWIM register
manipulation?  I am looking into writing an application such like apple
file exchange, but using a specialized format that needs to be read
in pc's.   Any ideas??

      Thanks for your help!

     -Larry



- -------------------------

From: [e-mail] (Steve Christensen)
Date: 6 Mar 92 05:17:44 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Lawrence Kelly) writes:

>Just wondering if anyone has done any type of direct programming of
>the SWIM chip in systems so equipped.  Is there a standard Mac system
>call to use SWIM commands, or would you have to do direct SWIM register
>manipulation?  I am looking into writing an application such like apple
>file exchange, but using a specialized format that needs to be read
>in pc's.   Any ideas??

The only safe way to deal with floppy disks is by calling the floppy
disk driver.  Not doing so means you run into compatibility problems
on the IIfx, Quadra 700, and all of the portables, since dealing with
the SWIM chip on those systems is somewhat non-standard.  The "standard"
interface to the SWIM chip is the floppy driver; there is no other
official support for dealing with the SWIM chip.

If the specialized format you're talking about is either the 1MB (9
sectors/track) or 2MB (18 sectors/track) format with 512 byte sectors,
you're in luck since that's what the floppy driver can deal with.  If
it's another format (either different number of sectors/track or different
sector size), you can't get there from here without talking to the
hardware, which is a bad idea.

If the format is different because it uses a different file system/
directory structure overlayed on a standard physical format, you'll need
to write a foreign file system to convert the information on the disk
to something the Mac can deal with.  In that case, you don't need to
play around with the disk itself.

steve
- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen            Never hit a man with glasses.
  [e-mail]            Hit him with a baseball bat.

---------------------------

From: [e-mail] (Gerard Hammond)
Subject: char to keycodes
Date: 3 Mar 92 00:08:39 GMT
Organization: University of New England, Armidale, Australia

This may be an easy one? I hope so.

In Think PascaL, how do I convert a char variable into the
the keycode for use with GetKeys.

The char is obtained from reading in an edit text box in a dialog
and then the char is extracted from the string. I then want to
see if this key is being held done later on so that I can
do the animation. I have tried getnextevent and converted it to char codes
but the keymapping with getkeys is much faster. Hence the problem.

System 7.0.0
ci
No VM

I no these shouldn't make any difference though.
Thanks very much for any help!


              /\
       ___    | \              Gerard Hammond
     /    \__/   \             [e-mail]
    /             \            Dept., of Chemistry
   /               \           University of New England
   \             * /           Armidale NSW 2351
    \    ____     /            Australia.
     \__/    \___/
               __
               \/

- -------------------------

From: [e-mail] (Gerard Hammond)
Date: 6 Mar 92 00:16:03 GMT
Organization: University of New England, Armidale, Australia



Here is a summary of replies to a question I asked about how to
convert char variables into keycodes (as in the form generated from the
getkeys comand.
Thanks to everyone who was interested and those who could help.
best regards

Gerard Hammond
[e-mail]
(In sunny warm Australia)


Subject: char to keycodes

>From [e-mail] Wed Mar  4 00:50:19 1992
To: [e-mail]
Status: RO

I see 2 solutions
- - Get the keycode first instead of the char in your dialog.
- - Search in KCHR resource. I have a piece of code in Think C that does
this. I wrote this to be able to use an american program badly written
on a french keyboard : I sent him the right char with the american
equivalent keycode...
The first may be easier for your needs, the second in the only general
purpose way.
Eric Aubourg

**********************************


>From [e-mail] Wed Mar  4 05:00:42 1992
From: [e-mail]  (Gabriel Lawrence)
Subject: read the keys as a keymap originally...
Status: RO


This may be an easy one? I hope so.

In Think PascaL, how do I convert a char variable into the
the keycode for use with GetKeys.

The char is obtained from reading in an edit text box in a dialog
and then the char is extracted from the string. I then want to
see if this key is being held done later on so that I can
do the animation. I have tried getnextevent and converted it to char codes
but the keymapping with getkeys is much faster. Hence the problem.

- ------

Why not read the keys as a keymap originally?  if that isn't helpful I
think theres something in inside mac about converting.... I don't quite
remember for sure... but check it out...


****************************************************

>From [e-mail] Thu Mar  5 19:33:01 1992

In article <[e-mail]> you write:
>In Think PascaL, how do I convert a char variable into the
>the keycode for use with GetKeys.

Well, the index of the bit in GetKeys is, more or less, the
virtual keycode, and virtual keycodes are converted to
Mac ASCII with KeyTrans (see Inside Mac V, TN 160, and the
international cancelling Tech Note).

Good luck...  hope you've gotten it working by now.

Grobbins         [e-mail]

---------------------------

Organization: Senior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
Date: Tue,  3 Mar 1992 00:52:47 -0500
From: Vivek Gupta <[e-mail]>
Subject: New Programmer Needs Help!!

Hi,

I would like to work on a script interface system, but what I have found
in IM I-VI does not explain it well enough for me.  I was wondering
where I could find more documentation on script interface systems and
the Script Manager ???

Thanx in advance,
Vivek Gupta

- -------------------------

Organization: Senior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
Date: Wed,  4 Mar 1992 15:50:36 -0500
From: Vivek Gupta <[e-mail]>

Hi,

I would like to work on a script interface system, but what I have found
in IM I-VI does not explain it well enough for me.  I was wondering
where I could find more documentation on script interface systems and
the Script Manager ???

ANY POINTERS AT ALL WOULD HELP.

Thanx in advance,
Vivek Gupta


---------------------------

From: [e-mail] (David Fry)
Subject: Speaker-independent continuous-speech recogni
Date: 3 Mar 92 09:02:54 GMT
Organization: Harvard Math Department

In article <[e-mail]> [e-mail] (Amanda Walker) writes:
>    <[e-mail]>
>[e-mail] (Donald T. Major) writes:
>> All the posts quote Apple as claiming 1 meg of RAM for the product; of
>> course, the article also seems to claim that a relatively small vocab
>> was used for the demo (I seem to recall seeing the figure of 2-300
>> words being mentioned--the article DID say that it wasn't explicitly
>> made clear by Apple).
>
>With that small a vocabulary, it's quite practical, and I'm quite
>willing to believe their claims.  This would, however, limit its
>usefulness as well.  Even so, it would be quite a studly addition to Mac
>system software...

Actually, the article doesn't say that is the vocabulary size,
it says that each command is "assocatiated" with 2-300 words,
whatever that means.  Someone else said the vocabulary is
100,000 words, but that seems outlandish.  On the GMA show
this morning, Kai-Fu Lee said it was tested on thousands of
different speakers and a *trillion* different sentences.
The demo was fairly impressive I suppose, but I can't help but
think I'd feel goofy saying "Casper, open my calendar" all
day.

But, like you say, it will definitely be studly.

David Fry                               [e-mail]
Department of Mathematics               [e-mail]
Harvard University                      ...!harvard!huma1!fry
Cambridge, MA  02138

- -------------------------

From: [e-mail] (Samuel John Kass)
Date: 3 Mar 92 12:54:29 GMT
Organization: Freshman, MCS general, Carnegie Mellon, Pittsburgh, PA


   WHen I heard about this, my dream was to get one of them new modems
(you know, the ones with voice digitization from the phone lines, and
voice output over the phone lines), and pipe that through the new voice
recognition/ output.  Then, you call your Mac up, and say, "Hey Mac,
what was I supposed to buy at the grocery market again?"  And in a HAL
like voice it would reply, "Eggs, Milk, and Bread, you moron."
    I suppose there are more practical uses than the above application,
but you get the picture.
    --Sam
P.S. I suppose my command to it would probably, more realistically,
sound like, "Macintosh, Open HD:SamStuff:ShoppingList, Read" but hey, I
can dream.

---------------------------

From: [e-mail] (William T. Bridgman)
Subject: How do I pass a string to an object in THINK C?
Organization: Clemson University
Date: Tue, 3 Mar 1992 12:54:09 GMT

I've checked several sources, including the c++ FAQ (which uses a
different i/o arrangement) and have not found a method that works.
I'm trying to pass a string to an object and then print that string
from the method inside the object.  I can get it to work with
numbers, but it seems to choke on strings, even when I just pass a
pointer.

Here is a sample of the minimum code that reproduces the problem:

- ---- start here ----
#include <oops.h>
#include <string.h>
#include <stdio.h>

#define LENGTH 30

/************ Class Definition ************/
class CSample {
    char name[LENGTH];
public:
    void initialize(char n[]);
    void print(void);
};
/********** Method Definitions ************/
void CSample::initialize(char n[])
{
    strcpy(name,n);
}
void CSample::print()
{
    printf("\nModel Name: %s\n",name);
}
/************ Main Program ***************/
main()
{
    CSample *test_run;

    test_run=new CSample;
    test_run->initialize("Test");
    test_run->print();
    delete test_run;
}
- ---- end here ----

Ideally, this should print:

Model Name: Test

Instead I get something like:

Model Name: (some random garbage characters)

Any suggestions as to what I'm doing wrong?

Thanks...Tom
- -----------------------------------------------------------------------
|  William T. "Tom" Bridgman, M.S.   | [e-mail]     |
|  Department of Physics & Astronomy |                                |
|  Clemson University                |"Black Holes under Construction.|
|  Clemson, SC   29634-1911          |       WATCH YOUR STEP!"        |
- -----------------------------------------------------------------------

- -------------------------

From: [e-mail] (Eric W. Sink)
Date: 3 Mar 92 18:17:03 GMT
Organization: University of Illinois at Urbana-Champaign

In <[e-mail]> [e-mail] (William T. Bridgman) writes:

>/************ Class Definition ************/
>class CSample {
>    char name[LENGTH];
>public:
>    void initialize(char n[]);
>    void print(void);
>};

I would declare initialize as void initialize(char *);

Keep in mind that the CSample object is (probably) a relocatable
handle, and you should lock it before passing a pointer to its
contents to a non-trivial routine like printf.

- --
Eric W. Sink,  Spatial Analysis and Systems Team
USACERL, P.O. Box 9005, Champaign, IL 61826-9005
1-800-USA-CERL x449,   [e-mail]

---------------------------

From: [e-mail] (Lloyd Lim)
Subject: FixMul tip
Date: 3 Mar 92 12:42:46 GMT
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science

Here's a tip for people who use Fixed and Fract math.  Although it's not
stated explicitly in IM I, FixMul can be used with other types in the
same way as FracMul.  This is rather obvious, but I never thought about
it until I happened to have both IM I and IM IV open next to each other
today.

In the style of IM IV, you can also add the following to the
description of FixMul:

Note that FixMul effects "type * Fixed -> type":

Fixed   * Fixed   -> Fixed
LONGINT * Fixed   -> LONGINT
Fixed   * LONGINT -> LONGINT
Fract   * Fixed   -> Fract
Fixed   * Fract   -> Fract

Figuring out why this works is left as an exercise for the reader.  :-)

+++
Lloyd Lim     Internet: [e-mail]
              America Online: LimUnltd
              Compuserve: 72647,660
              US Mail: 224 Lysle Leach Hall, U.C. Davis, Davis, CA 95616

- -------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 4 Mar 92 15:28:36 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Lloyd Lim)
points out that FixMul will multiply a value of any of a bunch of types by a
Fixed to return a value of the same type.

Yup, and a similar thing goes for FixDiv and FixRatio, too--they will divide
two values of the same type to return a value of type Fixed. Note that
FixDiv is just a 32-bit version of FixRatio; the only reasons left to use
FixRatio instead of FixDiv are: 1) since it works on 16-bit rather than
32-bit arguments, it may be faster; or 2) you still want to maintain
compatibility with the 64K ROM.




(OK, maybe I *should* have put a smiley on that second reason...)

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
Chemist invents new edible metal, calls it "iumium".

- -------------------------

From: [e-mail] (Lloyd Lim)
Date: 4 Mar 92 12:21:09 GMT
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>In article <[e-mail]>, [e-mail] (Lloyd Lim)
>points out that FixMul will multiply a value of any of a bunch of types by a
>Fixed to return a value of the same type.
>
>Yup, and a similar thing goes for FixDiv and FixRatio, too--they will divide
>two values of the same type to return a value of type Fixed. Note that
>FixDiv is just a 32-bit version of FixRatio; the only reasons left to use
>FixRatio instead of FixDiv are: 1) since it works on 16-bit rather than
>32-bit arguments, it may be faster; or 2) you still want to maintain
>compatibility with the 64K ROM.

Thanks, Lawrence.  I guess I overlooked FixRatio because it doesn't take
Fixed or Fracts, only 16-bit numbers, like you pointed out.

I didn't mention the behavior of FixDiv because it is documented in
IM IV.  FixMul was documented in IM I, before Fracts came around, so
the notes about return types aren't there.

My 5 year old cousin uses a hand-me-down 512K Mac.  I have a hard time
explaining to my aunt and uncle why all of the software I write doesn't
work on their Macintosh.  :-(

+++
Lloyd Lim     Internet: [e-mail]
              America Online: LimUnltd
              Compuserve: 72647,660
              US Mail: 224 Lysle Leach Hall, U.C. Davis, Davis, CA 95616

---------------------------

From: [e-mail] (Ramesh Chandak)
Subject: Very Simple Questions
Date: 3 Mar 92 17:40:09 GMT
Organization: GTE Laboratories Incorporated, Waltham MA

For lack of appropriate language newsgroups, I'm posting this to the
newsgroups I thought would be okay. These are very elementary questions
about programming constructs and syntax ; i hope to get a quick response
from the net; hence the posting.

( a ) how do you define a subroutine in BASIC ?
      how do you pass arguments to it ?
      eg. can you say
      sub example( x y )
        ...
        ...
        ...
      end sub

( b ) can one write recursive code in BASIC ? if not, how do u represent
      recursive code in BASIC ? for example the famous fibonacci sequence

( c ) in C, one can write a forever loop as
      for ( ;; ) {
           ...
      }
      how do you write it in BASIC and FORTRAN ?

( d ) in C, one can get out of a FOR loop using a break statement ;
      how do you get out of it in BASIC and FORTRAN ?

please email your responses to Ramesh at [e-mail]. Thanx.

- -------------------------

From: [e-mail] (Bob Pendelton)
Organization: HaL Computer Systems, Inc.
Date: Tue, 3 Mar 1992 21:31:42 GMT

At the risk of sounding pedantic, and in hopes of heading off the
flame war building behind this question, I have to ask; Which BASIC
and which FORTRAN? If the answer is ANSI standard FORTRAN and BASIC, I
have ask which ANSI standard. If you mean a specific IMPLEMENTATION of
these languages, please state which implementation you are asking
about.

You see, there are at least half a dozen different implementations of
each of these languages on PCLones, many more when you cross over into
other machines, and they are all different.

            Bob P.

P.S.

Very bad karma to cross post to a mac group and a ibm.pc group, very
bad indeed...

- --

| Bob Pendleton              | Engineering Anathema:                     |
| [e-mail]               |   1) You've earned an "I told you so."    |
| Speaking only for myself.  |   2) Our customers don't do that.         |

---------------------------

From: [e-mail] (Mark A. Steele)
Subject: "Please insert disk ^0" Help
Date: 3 Mar 92 23:01:05 GMT
Organization: National Geophyical Data Center, Boulder, Colorado

I am writing an app that requires a specific disk to be mounted.
The "Please insert Disk ^0" dialog is the way I would like to go.

Is this particular dialog (and filter) predefined in the Mac
ToolBox somewhere or will I have to design and write my own?

If I must write my own, is there sample code for how this might
be done? (I have a rather simple version running, but I don't
know what all should go into the event loop, and sometimes it
crashes)

- -Mark Steele
[e-mail]

- -------------------------

From: [e-mail] (Mark A. Steele)
Date: 4 Mar 92 16:50:56 GMT
Organization: National Geophyical Data Center, Boulder, Colorado

In article <[e-mail]> [e-mail] (Mark A. Steele) writes:
>I am writing an app that requires a specific disk to be mounted.
>The "Please insert Disk ^0" dialog is the way I would like to go.
>
>Is this particular dialog (and filter) predefined in the Mac
>ToolBox somewhere or will I have to design and write my own?
>
>If I must write my own, is there sample code for how this might
>be done? (I have a rather simple version running, but I don't
>know what all should go into the event loop, and sometimes it
>crashes)
>
>-Mark Steele
>[e-mail]
>
I thank the people who have responded to my question, I feel that I
might want to elaborate on what I need a little bit more.

The app sits on the hard drive, and requires a specific CD-ROM to be
inserted. I want to make sure that the users have placed the CD into
the drive before I continue (the CD contains a database and needs to
be accessed by several platforms, that and our time and cost don't
justify having the Macintosh app sit on the CD itself).

What I want to do is:
    Check to see if a volume is mounted (this works)
    If it isn't mounted then put up a modal dialog
        requesting the named disk. (this works)
    In the modal filter, request a disk inserted event (works)
    If the disk is inserted, find out the name (works)
    If the names are the same, I assume the correct disk is
        inserted and return TRUE (crashes)
    If none of the above is true, eject the just inserted disk
        if disk insert event and return FALSE (sorta works).

Now the big question is how to deal with the two events in the filter
one is passed in via parameters, the other one is declared locally for
the disk insert event; should I reuse the parameter event? Does anybody
have a better idea for polling for a specific disk?

- -Mark Steele
[e-mail]

---------------------------

From: [e-mail] (Jerry Frain)
Subject: Error recovery in THINK C (was Re: Suggestion to the Developers of Think C)
Date: 4 Mar 92 07:37:24 GMT
Organization: Kansas State University

Before you hit 'n' because this article is so long and boring, I have
two suggestions to add:

    1) error recovery should be an option in THINK C

    2) implement a key sequence to parse the error list, and take
           the cursor to the file and line of the next error [like the
       next-error function (ESC-` macro) in emacs]

Now, on with the follow-up:

[e-mail] writes:

> In article <[e-mail]>, [e-mail] (Brent) writes...

>>I definitely agree with Brian on this point.  That is the one "feature"
>>of Think C that I truly hate.  I'm taking a compiler design course now
>>. . . .
>>A logfile would free programmers from the "let's find the next error
>>and recompile" methodology/rut that Think C FORCES us into.

> I have to disagree with Bren on this point for the same reason that has been
> pointed up numerous times: having it stop is advantageous in most cases.

Not providing error recover is typically NOT advantageous, unless you
lead a really, really boring life and like to recompile your program a
lot.

For every error in a file, that file has to be *completely*
recompiled.  Does that sound like a time-savings to you?

The worst case example is when there is an error on every line of the
program.  Without error recovery, the number of lines that are
compiled is (N * (N + 1)) / 2, where N is the number of lines in the
file.

With error recovery, if the programmer correctly fixes each error
(there is that chance, and not having error recovery does not give you
that chance), 2 compiles of the entire file is necessary, and hence 2N
lines are compiled.  A little arithmetic shows us that error recover
wins if N > 2.

Most of my programs are larger than 2 lines.

Even if there are only two errors in a file, if they are in the second
half of the file, then the number of lines compiled, if a compiler does
not have error recovery, will be greater than 2N.

I'd *much* rather read USENET news while my file compiles in the
background, then have the whole list of errors for the file, fix them
all and recompile it once (again, while I am reading news), and be
done with it.

Any compiler that doesn't have error recovery is not what I would call
a ``production-level'' compiler.

> One thing I always hated about MPW was letting it compile for ten
> minutes, only to find some hundred errors, all cascading off of one
> or two minor problems.

Sounds like a bad experience with a single compiler, causing you to
make sweeping generalizations about error recover in general.

> Logfiles do not IMHO make programming easier, it just forces you to
> compile the whole darn file before finding out what's wrong.

Yah, but then you can fix *everything* that's wrong before recompiling
it just one more time.

> And to Brian: I don't normally have 100 files to recompile, because
> I'm working error by error, rather than making changes to 100 files
> and seeing if they worked out correctly.

While this typical of programs being developed from scratch, try
porting a large program to the Mac (or even to THINK C 5.0, if the
program was developed using a different Mac compiler) some time.

> If anything, I program faster in Think C because of the quick
> find-and-fix-error system.

I believe that compilers that don't implement error recovery provide
this illusion of development speed because the code is compiled, and
WHAM, control is returned to the programmer quickly upon detecting the
first error.

Users rarely count the number of times that they tell the compiler to
recompile a file before they get to compile completely.

  --Jerry Frain, [e-mail]

- -------------------------

From: [e-mail] (Russell S. Finn)
Date: 4 Mar 92 18:12:26 GMT
Organization: MIT Laboratory for Computer Science

In article <[e-mail]>, [e-mail] (Jerry Frain) writes:
|> The worst case example is when there is an error on every line of the
|> program.  Without error recovery, the number of lines that are
|> compiled is (N * (N + 1)) / 2, where N is the number of lines in the
|> file.

But this is an unrealistic argument.  If you write a program with an
error on every line, then you've got worse problems than whether or
not the compiler stops on the first error.  THINK C's approach makes
sense if you assume that errors are sparsely distributed in a source
file, which is a reasonable assumption under normal circumstances.

In fact, I imagine that the majority of the time a file is compiled,
it contains no errors at all.  If that is the normal case, then why
not optimize for it?

|> With error recovery, if the programmer correctly fixes each error
|> (there is that chance, and not having error recovery does not give you
|> that chance), 2 compiles of the entire file is necessary, and hence 2N
|> lines are compiled.

You seem to be arguing a worst-case scenario on the one hand, and a
best-case scenario on the other, which hardly seems fair.

|> Any compiler that doesn't have error recovery is not what I would call
|> a ``production-level'' compiler.

Then you'll be surprised to learn that a large amount of the
commercially available software for the Macintosh was written with a
"sub-production-level" compiler.

|> > And to Brian: I don't normally have 100 files to recompile, because
|> > I'm working error by error, rather than making changes to 100 files
|> > and seeing if they worked out correctly.
|>
|> While this [is] typical of programs being developed from scratch, try
|> porting a large program to the Mac (or even to THINK C 5.0, if the
|> program was developed using a different Mac compiler) some time.

OK, you've got a point there (I've done some ports myself).  Under
such circumstances, THINK C's approach is possibly less useful.
However, it's hardly impossible, as you seem to suggest.  I ported the
latest versions of Bison and Flex to THINK C 5.0 in about half an hour.

* * *

The idea behind THINK C, which you seem unwilling to accept, is that
compilation (and linking) speed is of the greatest importance.

You seem to be making a lot of unnecessarily strong arguments which
essentially boil down to "I don't like THINK C because it doesn't have
error recovery."  Fine; then don't use it.  There are alternatives.
But don't suggest that those of us who use and like it have been
deluded into using low-quality software.

- -- Russell S. Finn
[e-mail]

- -------------------------

From: [e-mail] (Jerry Frain)
Date: 5 Mar 92 01:02:40 GMT
Organization: Kansas State University

[e-mail] (Russell S. Finn) writes:

> In article <[e-mail]>, [e-mail] (Jerry Frain) writes:

[ I present a worst case approach argument to support error-recovery ]

> But this is an unrealistic argument.  If you write a program with an
> error on every line, then you've got worse problems than whether or
> not the compiler stops on the first error.

This is quite true, which is why I stated the following in the
original article, which you conveniently cut out:

= Even if there are only two errors in a file, if they are in the second
= half of the file, then the number of lines compiled, if a compiler does
= not have error recovery, will be greater than 2N.

> |> Any compiler that doesn't have error recovery is not what I would call
> |> a ``production-level'' compiler.

> Then you'll be surprised to learn that a large amount of the
> commercially available software for the Macintosh was written with a
> "sub-production-level" compiler.

No, actually it does not surprise me at all.

> |> While this [is] typical of programs being developed from scratch, try
> |> porting a large program to the Mac (or even to THINK C 5.0, if the
> |> program was developed using a different Mac compiler) some time.

> OK, you've got a point there (I've done some ports myself).  Under
> such circumstances, THINK C's approach is possibly less useful.

*Possibly*?  Very gracious of you to let me have that one.

> However, it's hardly impossible, as you seem to suggest.

I suggested no such thing.  90% of my programming under THINK C is
porting (which is one of the reasons I am a big advocate for error
recovery).

> The idea behind THINK C, which you seem unwilling to accept, is that
> compilation (and linking) speed is of the greatest importance.

The speed at which N lines of code may be compiled is less important,
IMHO, than the total time spent compiling N lines until the N lines
are correct.  This is where error recovery is a win.

Obviously, most compiling is done during development.  It is quite
natural that if parts of a program are compiled less often, the
development time is likely to be shorter.

> You seem to be making a lot of unnecessarily strong arguments which
> essentially boil down to "I don't like THINK C because it doesn't have
> error recovery."

Actually no, I use THINK C quite often, but that doesn't mean it can't
be improved.  One way I believe it can be improved is the addition of
error recovery.

> But don't suggest that those of us who use and like it have been
> deluded into using low-quality software.

I am not questioning the quality of THINK C, it is a fine product.
However, I am suggesting a way to improve it, IMHO.

  --Jerry Frain, [e-mail]


- -------------------------

From: [e-mail] (Russell S. Finn)
Organization: MIT Laboratory for Computer Science
Date: Fri, 6 Mar 1992 00:24:41 GMT

OK, let me see if I can get myself out of this one:

In article <[e-mail]>, [e-mail] (Jerry Frain) writes:
|> [e-mail] (Russell S. Finn) writes:
|>
|> [ I present a worst case approach argument to support error-recovery ]
|>
|> > But this is an unrealistic argument.  If you write a program with an
|> > error on every line, then you've got worse problems than whether or
|> > not the compiler stops on the first error.
|>
|> This is quite true, which is why I stated the following in the
|> original article, which you conveniently cut out:
|>
|> = Even if there are only two errors in a file, if they are in the second
|> = half of the file, then the number of lines compiled, if a compiler does
|> = not have error recovery, will be greater than 2N.

I cut down quotes to keep the bandwidth down, not out of any attempt
to take comments out of context.  If you feel that I misrepresented
your argument in my reply, then I may have misunderstood the point you
were trying to make.

In your two-error case, the expected number of lines compiled without
error recovery is 2.5N, as opposed to 2N, a 20% difference.

|> > OK, you've got a point there (I've done some ports myself).  Under
|> > such circumstances, THINK C's approach is possibly less useful.
|>
|> *Possibly*?  Very gracious of you to let me have that one.

Geez, I'm not picking on you; I've never met you.  I'm just presenting
my side of the discussion.

|> > The idea behind THINK C, ..., is that
|> > compilation (and linking) speed is of the greatest importance.
|>
|> The speed at which N lines of code may be compiled is less important,
|> IMHO, than the total time spent compiling N lines until the N lines
|> are correct.  This is where error recovery is a win.

In your opinion, yes, but not in the opinion of the designer of THINK
C, one can infer.  You left out the part of *my* message that claims
that most compilations encounter few errors or none at all, so
optimizing for this case is reasonable; I assume this means you
disagree with that view.

We're making a lot of fuss over nothing, so let me back out as
gracefully as I can manage (if that doesn't violate the Usenet code of
conduct :-).  We obviously disagree over the importance of adding
error recovery to THINK C; we can both look forward to THINK C 6.0 to
see what changes have been made.

(Acutally, I wouldn't mind the compiler being modified to handle error
recovery if (a) it didn't slow the compiler down appreciably, or (b)
it was a user-configurable option, like optimizaton is now -- or even
along the lines of holding down the option key when compiling to
invoke error recovery mode.)

- -- Russell S. Finn
[e-mail]

---------------------------

End of C.S.M.P. Digest
**********************